<body>

<h2><a name="searching"></a>Search terms</h2>

<p>

The search interface allows you to select capabilities to search for.
These can be typed directly in the search form, or selected from the
list, and then adding them to the form.  Note that browsers usually
permit making multiple  selections holding the <em>Ctrl</em> key while
clicking on the selections.

<h3>Sorting the Results</h3>

Search results can be sorted according to a user-defined policy which
can be set by selecting the degree of importance of several measures
from the pull-down menus below the search form.  The default values
are set not to influence the order in which results are presented to
the user.  The options which can be set are currently:

<dl>

  <dt> <strong>Number of packages</strong>
  <dd> You may prefer assemblies with few packages (probably what most
       users would want, in fact), or assemblies with a lot of
       packages, if you are planning ahead in the future.

  <dt> <strong>Number of unsatisfied requirements</strong>
  <dd> One measure of quality is the number of requirements which
       arose during the search and which ended up being unsatisfied.
       These might need to be fulfilled in order for the selected
       packages to work completely.  On the other hand, some
       unfulfilled requirements might cause selected packages to work
       only partially.  That may be enough for some purposes.

  <dt> <strong>Number of auxiliary requirements</strong>
  <dd> During the search, a number of auxiliary requirements (either
       fulfilled, or unfulfilled) can be
       needed in order to chain packages.  The more auxiliary
       requirements, the more links are needed in order for the
       assembly to work as a whole.  Diminishing them will probably
       lead to tighter assemblies, which are more adjusted to the
       initial requirements.

  <dt> <strong>Number of final capabilities</strong>
  <dd> This is the total amount of provided capabilities.  Again, the
       less provided capabilities, probably the better.  On the other
       hand, if the software being developed is to evolve in the
       future, an assembly with more capabilities (very probably
       related among them) will be beneficial in the long term.

  <dt> <strong>Ratio of fufilled capabilities</strong>
  <dd> The previous measures have the drawback that they are absolute,
       i.e., they do not work well to compare big assemblies with
       small ones.  By taking a ratio of fullfiled against unfulfilled
       capabilities, the <em>quality</em> of the assembly (taking into
       account what it gives, against what it stil needs) is
       expressed.

</dl>

<h3>Timeout</h3>

A timeout can also be set: if the search exceeds the time limit, only
the solutions found so far are taken into account.

<p>

<h3>Generalizations</h3>

The dictionary contains a number of generalizations, e.g., a
<em>editor</em> is a generalization of a
<em>syntax_coloring_editor</em> or, rather, a
<em>syntax_coloring_editor</em> is a kind of <em>editor</em>.  Some
packages which need just <em>editor</em> will be happy with any
editor, in particular with a <em>syntax_coloring_editor</em> if none
else is available.  This is an example of the use of a
<strong>safe</strong> generalization: going from a more general
requirement to a more particular one.  Moving the other way around
(e.g., using just an <em>editor</em> when a
<em>syntax_coloring_editor</em> is needed) is <strong>unsafe</strong>
use of generalizations: the package providing an <em>editor</em> might
fulfill only partially the needs for a <em>syntax_coloring_editor</em>.

<p>

However, and since packages can in the end be modified to suit the
particular needs, unsafe generalizations make it possible to return an
approximate solution, if the exact one does not exist.

<p>

<strong>Safe</strong> and <strong>unsafe</strong> generalizations can
be chained together.  This corresponds to <em>walking</em> up and down
in the generalization tree from one term to its siblings.  The number
of generalizations (safe and unsafe) can be set separately.


<h3>Including and Excluding Packages</h3>

Additionally, if one or more packages are required to be part of the
result, the user can ensure it by writing the name(s) of the
package(s) in the field "Include packages". If, on the contrary, one
or more packages are required <strong>not</strong> to be used, the
user can write their names in the field "Exclude packages".

<h2><a name="terms">Search Terms</a></h2>

<strong>Search terms</strong> are names of capabilities provided or
required by Open Source packages.  Typical capabilities are "compile C
programs", "produce XML files", "edit files", etc.  Each capability is
associated to a symbolic name in the dictionary.

<h2><a name="packages">Packages</a></h2>

An Open Source <strong>package</strong> is a source file, part of
source file, or collection of source files.  A package typically
implements a series of services, usually closely related.  The
services can be implemented in the form of a full-fledged library, or
as a series of procedures and functions which probably have to be read
and partially understood.

<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>

</body>
